One thing stands out to me.
libpkpass/password.py:
260: decrypt_entry : PKCS11_module_path given explicit default path

This function has it overwritten in a try block to match the given argument so that works. However there are other functions that do it differently elsewhere:

libpkpass/crypto.py:
123: pk_decrypt_string : PKCS11_module_path given explicit default path.
200: pk_sign_string : PKCS11_module_path given explicit default path.

These two both have a following popen line that takes PKCS11_MODULE_PATH. PKCS11_MODULE_PATH is set to the default at the start of the function, and I do not see any try block or way that PKCS11_MODULE_PATH is set back to the supplied argument for PKCS11_MODULE_PATH, and stays as the default path of PKCS11_module_path="/usr/local/lib/libykcs11.dylib" that is set in the function definition.

One thing stands out to me. libpkpass/password.py: 260: decrypt_entry : PKCS11_module_path given explicit default path

This function has it overwritten in a try block to match the given argument so that works. However there are other functions that do it differently elsewhere:

libpkpass/crypto.py: 123: pk_decrypt_string : PKCS11_module_path given explicit default path. 200: pk_sign_string : PKCS11_module_path given explicit default path.

These two both have a following popen line that takes PKCS11_MODULE_PATH. PKCS11_MODULE_PATH is set to the default at the start of the function, and I do not see any try block or way that PKCS11_MODULE_PATH is set back to the supplied argument for PKCS11_MODULE_PATH, and stays as the default path of PKCS11_module_path="/usr/local/lib/libykcs11.dylib" that is set in the function definition.

On closer inspection this has been addressed. However, current error handling will not report that a supplied PKCS11_MODULE_PATH is not valid.

One thing stands out to me. libpkpass/password.py: 260: decrypt_entry : PKCS11_module_path given explicit default path
This function has it overwritten in a try block to match the given argument so that works. However there are other functions that do it differently elsewhere:
libpkpass/crypto.py: 123: pk_decrypt_string : PKCS11_module_path given explicit default path. 200: pk_sign_string : PKCS11_module_path given explicit default path.
These two both have a following popen line that takes PKCS11_MODULE_PATH. PKCS11_MODULE_PATH is set to the default at the start of the function, and I do not see any try block or way that PKCS11_MODULE_PATH is set back to the supplied argument for PKCS11_MODULE_PATH, and stays as the default path of PKCS11_module_path="/usr/local/lib/libykcs11.dylib" that is set in the function definition.

On closer inspection this has been addressed. However, current error handling will not report that a supplied PKCS11_MODULE_PATH is not valid.

22ae40d should resolve this issue.